feat(android): let callers choose the JDK of the APK release job - #178

No actionable comments were generated in the recent review. 🎉

Merge Risk: ⚪ Minimal · up to 250c4

Android release callers can now select a compatible JDK, while callers omitting the input retain Java 25. No current merge-blocking risk is evident.

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

Independent local review

Reviewed head: 250c498a0c380edaaf54b5ed56ae5afad7fd3532

Verdict: not mergeable as is — one blocking item, and it is not in the diff. The required check "Validate GitHub Actions workflows" is red on this head because its job was never picked up by a runner; no lint step ran. The change itself has no findings. Once that check has been re-run and is green on this head, the PR is safe to merge.

What was checked

• Scope. One commit, five files (build-test-publish.yml, release-android-apk.yml, README.md, CLAUDE.md, renovate.json), 21 additions / 13 deletions. The diff contains nothing beyond what the description lists.
• Input declaration. java_version in release-android-apk.yml is type: string, required: false, default: "25", identical in shape to the same input in test-and-build.yml, publish-maven-central.yml and build-test-publish.yml.
• Use. The input is only consumed as java-version: of the actions/setup-java step (with: block). It reaches no run: step, so it needs no shell-level validation; the other three java_version inputs get none either and are used the same way.
• Pass-through. The orchestrator job release_android_apk passes java_version: ${{ inputs.java_version }}. build-test-publish.yml is the only caller of release-android-apk.yml in this repository.
• Unchanged default behaviour. On main the step has the literal java-version: "25" (since chore(deps): Update dependency java to v25 #175); the orchestrator default and the new input default are both "25", so a caller that does not set java_version gets the same JDK as before.
• Other JDK pins. All three actions/setup-java steps in the repository now read inputs.java_version; no literal JDK version is left in any workflow.
• actionlint. actionlint .github/workflows/*.yml run locally on this head: no output, exit code 0.
• Renovate. The two matchStrings of the Java custom manager were applied to every workflow file on this head and on the base. Base: four matches (three input defaults plus the literal in release-android-apk.yml). Head: four matches, all through the input-default pattern, one per file (build-test-publish.yml, publish-maven-central.yml, release-android-apk.yml, test-and-build.yml), each with value 25. Nothing is matched twice and nothing is lost; the removed literal was the only one. The renovate.json change is the description text of one package rule; matchDepNames, matchUpdateTypes and dependencyDashboardApproval are untouched. renovate-config-validator --strict --no-global accepts the file.
• Documentation. The edited passages in README.md (input table row, Android feature list) and CLAUDE.md (Renovate section) match the code and each other. A search of both files for "android", "JDK", "java" and "24" found no remaining mention of a separate Android pin or of JDK 24. On main these passages still say the Android pin is 24, which has been wrong since chore(deps): Update dependency java to v25 #175; this PR corrects that.
• Design. One java_version for the build jobs and the Android job. A caller that builds with tool: ./gradlew or mvn and ships an Android app whose wrapper needs a different JDK cannot express that through the orchestrator. The description states this trade-off in "For callers". The request in Android release job runs on JDK 25, which Gradle 8 does not support #177 (second option: an input on the Android workflow, current value as default) is met.
• Description claims. Gradle's compatibility table lists 9.1.0 as the first version that runs on Java 25 and 8.14 as the first for Java 24, so "wrappers older than 9.1 cannot run on JDK 25" is correct. The "For callers" section is accurate: this PR alone changes nothing for a caller that does not set the input.
• Other reviews. CodeRabbit finished with no actionable comments; there are no inline review comments. GitGuardian passed.

Blocking

• The required check "Validate GitHub Actions workflows" is failed on this head. The job did not start on a runner, so the failure says nothing about the change, but the repository requires this check and it has not actually validated this commit. Re-run it; no code change is needed. (The same lint run locally is clean, see above.)

Fix in PR

none

Follow-up

• Calling repositories still have to set the input (no issue). Merging closes Android release job runs on JDK 25, which Gradle 8 does not support #177, but an app_root caller with a Gradle wrapper older than 9.1 keeps failing in build apk until it passes java_version itself. For a Gradle 8.14 wrapper, Gradle's compatibility table allows running on Java up to 24; Android Gradle Plugin 8.13 needs at least JDK 17, and an app compiling with Java 21 source/target level needs at least 21. So "21" (LTS, the value the README suggests) to "24" work, "25" does not. That change belongs in the calling repository. Tracked in Android release job needs java_version: Gradle 8.14.3 cannot run on JDK 25 numveil#98.
• inputs.app_root is interpolated directly into run: scripts in release-android-apk.yml (build apk, sign apk, align apk) instead of going through env: (no issue). These lines are not touched by this PR and the value comes from the caller's own workflow file, so the risk is low, but it does not match the input-handling convention documented in CLAUDE.md. Tracked in release-android-apk.yml interpolates app_root directly into run scripts #179.

Not covered

• The Android release job was not executed with this change: it only runs on a push to the default branch of a calling repository with app_root set. That actions/setup-java installs the requested Temurin major and that the APK build then succeeds with a non-default value is inferred from the action's documented java-version input, not observed.
• The Renovate check applied the configured regular expressions to the files with a script and ran the config validator; no Renovate run against the repository was performed.

Independent local review

Reviewed head: 250c498

Verdict: mergeable

This is round 2. The head is the same commit as in round 1 (one commit, no changes since). All checks on the head are now green, and the base branch has moved on without conflicting with the change. I found no blocking and no fix-in-PR items.

What was checked

• Head and commits. The head of the PR is the commit named above; it is the only commit on top of the base. Five files change (build-test-publish.yml, release-android-apk.yml, README.md, CLAUDE.md, renovate.json), 21 additions and 13 deletions. The diff contains nothing beyond what the description lists.
• Input and pass-through. release-android-apk.yml declares java_version as an optional string input with default "25" and the same description string as the three existing java_version inputs. It is consumed only as java-version: of the actions/setup-java step and reaches no run: script. The orchestrator job that calls the Android workflow passes inputs.java_version; that is the only caller in the repository. No literal JDK version is left in any workflow; all three actions/setup-java steps read the input.
• Unchanged default. Without the input the Android job gets "25", the same literal that is on the base branch, so behaviour for callers that do not set the input does not change.
• Mergeability against the current base. The base branch has gained commits since round 1. One of them (the change that moved app_root and the release tag into env: in release-android-apk.yml) touches the same file. I computed the merge of the head into the current base: it completes without conflicts, and the result differs from the current base only in the same five files and the same hunks as the PR diff (the java_version input and its use in the Android workflow, the pass-through line, and the three documentation/config text edits). The merged tree keeps the env: handling of app_root in the build, sign and align steps.
• Lint of the merged result. actionlint over all workflow files of the merged tree: no output, exit code 0. renovate-config-validator --strict --no-global on the merged renovate.json: config validated successfully.
• Renovate custom manager. The two matchStrings of the Java manager, applied to the merged workflow files, match exactly once per file in test-and-build.yml, publish-maven-central.yml, build-test-publish.yml and release-android-apk.yml, each with value 25. The removed literal pin was the only one matched by the first pattern, so nothing is lost and nothing is matched twice. The edit in renovate.json is only the description text of the Java package rule; the matchers, update types and dependencyDashboardApproval are unchanged.
• Documentation. The README.md input-table row and Android feature entry, and the Java paragraph in CLAUDE.md, agree with the code: one default (25) across four workflows, caller override via java_version, orchestrator forwards it to the Android job, and JDK 25 needs Gradle 9.1+. A search of both files finds no remaining mention of a separate Android pin or of JDK 24 for Android.
• Description claims. "Default 25, behaviour unchanged" and "the orchestrator input is passed on" are correct. The "For callers" caveat is correct: the PR alone does not make an affected caller's Android job pass, and the single input also applies to ./gradlew and mvn builds of the same caller. The verification claims (actionlint, Renovate validator, match strings finding the new default) reproduce as stated.
• Version bump. The repository has no package.json, pyproject.toml or Cargo.toml, so there is no manifest to bump.
• CI state. All checks on the head are green: the workflow lint, the secret scan and the CodeRabbit review. The PR reports as mergeable with a clean merge state.
• Other reviews and comments. CodeRabbit reviewed this head and reported no actionable comments; there are no review threads or inline comments. The only other comment is the round 1 review.
• Linked issues. The description closes the issue that asked for a caller-selectable JDK; it is open and the PR is what it asks for (second option, input on the Android workflow with the current value as default).

Status of the findings of round 1

• Blocking: required check "Validate GitHub Actions workflows" failed because its job never ran on a runner. Resolved. The check has been re-run on this same head and passes; my local actionlint run (also on the merged result) is clean too.
• Fix in PR: none. Nothing to resolve.
• Follow-up: calling repositories with a Gradle wrapper older than 9.1 must set java_version themselves. Still applicable and still tracked in the issue in the numveil repository referenced in round 1. I checked that the issue exists and is open, and that it says what the review claims: the Android release fails in build apk on JDK 25 with a Gradle 8.14.3 wrapper, the caller has to pass java_version in its build-projects.yml (21 to 24 work, 21 being the LTS), and updating the wrapper to 9.1 or newer is a later, separate change. This is outside the scope of this PR.
• Follow-up: inputs.app_root interpolated directly into run: scripts of release-android-apk.yml, tracked in release-android-apk.yml interpolates app_root directly into run scripts #179. No longer applicable. The issue exists and described the finding accurately, and it has since been closed by the merged change that moved app_root into env: for the build, sign and align steps. I verified that in the merged result (APP_ROOT is set via env: and used as a shell variable in all three steps).

Blocking

none

Fix in PR

none

Follow-up

none new. The caller-side follow-up from round 1 is tracked in the numveil repository (see above); no additional issue is needed for this review.

Not covered

• The Android release job was not executed with this change: it only runs on a push to the default branch of a calling repository that sets app_root. That actions/setup-java installs the requested Temurin major and that an APK build succeeds with a non-default value is inferred from the action's documented java-version input, not observed.
• No Renovate run against the repository was performed; only the configured regular expressions and the config validator were applied to the files.
• The merge of the head into the current base was computed locally, not performed; a later change to the base branch after this review could alter the result.